home *** CD-ROM | disk | FTP | other *** search
/ kermit.columbia.edu / kermit.columbia.edu.tar / kermit.columbia.edu / newsgroups / misc.20020314-20021006 / 000084_fdc@columbia.edu_Mon May 20 18:04:59 EDT 2002.msg < prev    next >
Text File  |  2002-10-06  |  3KB  |  74 lines
  1. Article: 13378 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!news.columbia.edu!news-not-for-mail
  3. From: fdc@columbia.edu (Frank da Cruz)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: REGET not as clever as RESEND?
  6. Date: 20 May 2002 18:04:44 -0400
  7. Organization: Columbia University
  8. Lines: 57
  9. Message-ID: <acbrts$1c7$1@watsol.cc.columbia.edu>
  10. References: <acbqst$bj2$1@panix3.panix.com>
  11. NNTP-Posting-Host: watsol.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 1021932286 17489 128.59.39.139 (20 May 2002 22:04:46 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 20 May 2002 22:04:46 GMT
  15. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13378
  16.  
  17. In article <acbqst$bj2$1@panix3.panix.com>,
  18. David Combs <dkcombs@panix.com> wrote:
  19. : RESEND does a pretty good job of almost instantly
  20. : recovering up to the %done that it had been
  21. : at when the prior transfer crapped out.
  22. : 
  23. : REGET seems to me so far to do a much POORER
  24. : job of doing that, like recovering up to only
  25. : maybe 1/3 of how far the prior get had gotten,
  26. : and then rereading a whole lot of stuff that
  27. : had (presumably) already been read in the prior
  28. : kermit-run.
  29. : 
  30. : Am I the only one who has seen this?
  31. : 
  32. It doesn't ring a bell.  Are you saying it corrupts
  33. the file, or just takes longer to resynchronize before
  34. resuming the download?
  35.  
  36. : (NOTE: I was using -i)
  37. : 
  38. : QUESTION: what is the SIZE of the blocks
  39. : that kermit sends?  (by default)
  40. : 
  41. The sender sends blocks (packets) of whatever length
  42. the receiver tells it to.  SHOW PROTOCOL at the
  43. receiver, see the receive packet length.
  44.  
  45. : Now, kermit registers 100%, but starts getting
  46. : errors (two per second) trying to get the last
  47. : several bytes, it seems.
  48. : 
  49. That doesn't have anything to do with RESEND or REGET.
  50. If it happens, it's because of transmission errors,
  51. which could happen with any kind of file transfer.
  52.  
  53. Is this a straight dialup connection or a Telnet
  54. connection or what?
  55.  
  56. If straight dialup, what kind of modem?  What serial
  57. speed?  Are you using RTS/CTS (hardware) flow control?
  58.  
  59. If Telnet, the same questions about the underlying PPP
  60. driver.
  61.  
  62. What version of Kermit do you have on your end? (Panix
  63. has the latest, 8.0.201, on its end, at least if we're
  64. talking about the same Panix).
  65.  
  66. Just now I tried downloading a 3MB file from Panix,
  67. interrupting the download, REGET'ing the file, and
  68. repeating the process several times until it was fully
  69. downloaded.  There were no delays, no errors, no
  70. failures.  This was using Kermit 95 1.1.21 as a
  71. client.
  72.  
  73. - Frank
  74.